Bulk data editing actions

Do these operate upon dataIds or on version ids VariousConceptionsOfVersionedData

Movement to a different store ( ignoring movements to the datas current store)
Custom code which is run over selection
Updating data to match a new specification ( new version or different spec, possibly ignore conversions to different spec which would end up in blank data so no point in copying), update any to any, not just internal types can use the conversion data and spec differencing. So need to pick destination type and spec version if its versioned ^9e834f Delta change discernment and application design I think i can make ( updating data to a new spec) and ( updating data to a changing spec) the same problem
Addition of attributes with a specific value at a path
Removal of attribute at a path
Alteration to attribute data at a path
Rename of attributes
Addition of a value at a sequence index - takes an index which can be negative, takes a switch to determine whether the added value should be unique

ops= [
 ( "attribAddition", 1, 1, s, 0, 1), # Attribute changes in the version format require knowledge of the previous value
 ( "attribRemoval", 1, 1, s, 0, 1),
 ( "attribChange", 1, 1, s, 0, 1),
 ( "attribRename", 1, 1, s, 0, 1), # If we could create and discern optional unidirectional deltas then the versioned data can be updated in store
 ( "storeMovement", 0, 0, g, 1, 1),
 ( "runCode", 0, 0, s, 1, 1),
 ( "typeTransformation<map>", 0, 0, s, 0, 0), # Would slow next load speed
 ( "typeTransformation<direct>", 0, 0, s, 1, 1),
 ( "sequenceAddition", 1, 1, s, 0, 1),
 ( "", 0, 0, s, 0, 0),
 ( "", 0, 0, s, 0, 0),
 ( "", 0, 0, s, 0, 0),
 ( "", 0, 0, s, 0, 0),
]


( "", 0, 0, s, 0, 0),

So it seems we can manipulate arrays in some stores, we are generic here The actions should be designed for manipulating the data as it is represented in memory In python there are classes, sequences and maps pretty much so attrib funcs can handle classes and maps what about non string key maps? well in order to equality check the serialised format, we would need to do funky stuff so not now sequences and sets can be handled with

well arent these all the same as the delta transform sets, however some of them wouldnt be created by the calculateDelta function such as runCode some of those created by the delta funcs may not be able to be run by the store, but thats ok, full store support isnt feasible anyway due to their varying nature runCode could vary depending on whether it was run on load or at specified time, so if this was passed to a function on the store then we would need to specify whether to update those requiring memory loading at that moment or upon next load regardless i think specification version updates should be applied with a different function an advantage of passing these as delta transforms is that we already have the in memory mechanism to apply them should they be unsupported by the store The delta transform creation, formats and discernment would have to be reworked to support unidirectional transforms So unidirectional deltas are designed here: Unidirectional delta operation design

We can use a list of unidirectional deltas as arguments to update The store then either supports them and applies them instantly or it We also need the ability to define ConstructionSet s that only provide operation descriptions and applications with no construction function this is good as it is then simple to create a construction function from that point They are applied in the order specified

So how do sequence operations work in the SequenceMatcherDeltaTransformationSet well there is currently, ( insert, delete, replace)

called If a store cant support an edit operation then it should save a record and perform the operation upon load or in the background

maybe then the ability to specify an enforced preference of the application time, with no preffecence being available

So we may want to perform actions on data s which arent in memory, they may also be in memory. So we should use ids

MAAP